home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-x400ops-tbl-dist-part2.txt < prev    next >
Text File  |  1993-07-08  |  17KB  |  523 lines
  1.  
  2.         
  3. INTERNET DRAFT                                            Marko Kaittola
  4.                                                                    FUNET
  5.                                                             Jul 04, 1993
  6.                                                   Expires: January, 1994
  7.         
  8.         
  9.         
  10.         
  11.                       Mail based file distribution
  12.                        Part 2: Over-all structure
  13.         
  14.                              Marko Kaittola
  15.                                  FUNET
  16.         
  17.         
  18. Abstract
  19.         
  20.         Mapping between X.400 and Internet mail and X.400 routing
  21.         are normally done using a table-based approach. In practise
  22.         tables are normal (ASCII) files. In order to function
  23.         properly tables must be coordinated carefully. One major
  24.         problem is the lack of automated procedures. This memo -
  25.         together with it's companion document - proposes one
  26.         possible solution. This memo discusses the over-all
  27.         structure aspects, while the companion document discusses
  28.         the transactions between two nodes.
  29.         
  30.         The same solution can be used to transport binary files.
  31.         This way it is possible to mirror an entire archive with
  32.         an e-mail only connectivity.
  33.         
  34.         
  35. Status of this memo
  36.         
  37.         This document is an Internet Draft.  Internet Drafts are
  38.         working documents of the Internet Engineering Task Force
  39.         (IETF), its Areas, and its Working Groups.  Note that other
  40.         groups may also distribute working documents as Internet
  41.         Drafts.
  42.         
  43.         Internet Drafts are draft documents valid for a maximum of
  44.         six months.  Internet Drafts may be updated, replaced, or
  45.         obsoleted by other documents at any time.  It is not
  46.         appropriate to use Internet Drafts as reference material or
  47.         to cite them other than as a ``working draft'' or ``work in
  48.         progress.''
  49.         
  50.         Please check the 1id-abstracts.txt listing contained in the
  51.         internet-drafts Shadow Directories on nic.ddn.mil,
  52.         nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
  53.         munnari.oz.au to learn the current status of any Internet
  54.         Draft.
  55.         
  56.  
  57.  
  58. Kaittola                 Expires: January, 1994                 [Page 1]
  59.  
  60. DRAFT                 File distribution - structure                 DRAFT
  61.  
  62.  
  63.         Distribution of this memo is unlimited.
  64.         
  65.         
  66. Table of contents
  67.         
  68.         Abstract                                                    1
  69.         Status of this memo                                         1
  70.         Table of contents                                           2
  71.         1. Introduction                                             3
  72.         1.1. More details                                           3
  73.         1.2. About security                                         4
  74.         1.3. Terminology                                            4
  75.         2. Distribution                                             5
  76.         2.1. Receiving a file                                       6
  77.         2.2. Sending files                                          7
  78.         3. Client and server roles                                  8
  79.         4. Security consideratins                                   9
  80.         References                                                  9
  81.         Acknowledgements                                            9
  82.         Author's address                                            9
  83.         
  84.         
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116. Kaittola                 Expires: January, 1994                 [Page 2]
  117.  
  118. DRAFT                 File distribution - structure                 DRAFT
  119.  
  120.  
  121. 1. Introduction
  122.         
  123.         This paper defines a way on using the dialog defined in
  124.         [DST-DIALOG]. These two documents should be read together.
  125.         A third document should also be written. That document
  126.         [DST-MHS] should explain how the other two documents are
  127.         applied to the needs of X.400 world.
  128.         
  129.         This paper has grown from a real need: mapping and routing
  130.         information in the international R&D X.400 network must be
  131.         distributed automatically.
  132.         
  133.         The most obvious solution would be to use FTP, but
  134.         unfortunately this isn't always possible. Indeed, the only
  135.         common denominator seems to be some kind of e-mail
  136.         connectivity, so this is what the distribution must be based
  137.         on. Naturally, other distribution techniques may (and most
  138.         probably will) be used in addition to this.
  139.         
  140.         Using a directory (either dns or X.500) is a natural and
  141.         attractive alternative. This, however, is not yet realistic
  142.         in a global scale.
  143.         
  144.         This proposal tries to fulfill the following requirements:
  145.         
  146.         - Files must be distributed rather quickly. In practice
  147.           this means some minutes from one node to another. Files
  148.           should reach even their final destination within a
  149.           couple of hours.
  150.         - Transport errors and forged files must be automatically
  151.           identified (and appropriate actions taken).
  152.         - Management must be simple and require very little human
  153.           effort.
  154.         - Distribution must be based on e-mail.
  155.         
  156.         This task is simplified by the fact that files are normally
  157.         public in a sense that anyone may fetch and see them.
  158.         
  159.         
  160. 1.1. More details
  161.         
  162.         Tables (files) are collected in one place. (As of this
  163.         writing SWITCH is doing the X.400 coordination.)
  164.         Distribution is done in a more or less tree-like
  165.         hierarchy. However, to make it more robust, some level of
  166.         redundancy is needed. In this model there is only one root,
  167.         but below it there can be practically any kind of directed
  168.         graph.
  169.         
  170.         This model allows for a natural hierarchy of nodes, but
  171.         doesn't enforce it.
  172.  
  173.  
  174. Kaittola                 Expires: January, 1994                 [Page 3]
  175.  
  176. DRAFT                 File distribution - structure                 DRAFT
  177.  
  178.  
  179.         
  180.         As redundance easily leads to loops having some kind of loop
  181.         control is a mandatory requirement.
  182.         
  183.         Any level of hierarchy may generate local changes to the
  184.         files. These changes must propagate further down, but they
  185.         are expected not to escape outside their scope. This can be
  186.         achieved by using some kind of subtree that is rooted on a
  187.         node that makes those changes.
  188.         
  189.         Some support for version management is needed.
  190.         
  191.         
  192. 1.2. About security
  193.         
  194.         The companion document [DST-DIALOG] defines a secure way for
  195.         two systems can communicate together. If every dialog
  196.         between any two nodes is secure then the over-all system is
  197.         also secure. (Obviously cracking a node is still
  198.         possible. However, discussing it is outside the scope of
  199.         this document.)
  200.         
  201.         
  202. 1.3. Terminology
  203.         
  204.         A client is a node that receives files and a notification
  205.         about new files.
  206.         
  207.         A server is a node that sends files and a notification
  208.         about new files. If there is a bi-directional link between
  209.         any two nodes they can both be clients and servers to each
  210.         other.
  211.         
  212.         Terms client and server are relative to a particular pair of
  213.         nodes.
  214.         
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232. Kaittola                 Expires: January, 1994                 [Page 4]
  233.  
  234. DRAFT                 File distribution - structure                 DRAFT
  235.  
  236.  
  237. 2. Distribution
  238.         
  239.         Files are normally distributed by actively sending new files
  240.         when they have been received. It is also possible to poll a
  241.         file server to see if there are any new versions.
  242.         
  243.         Active sending is done in three phases (as described in
  244.         [DST-DIALOG]): new files are announced, they are requested
  245.         and finally sent.
  246.         
  247.         However, file distribution is not limited into tree-like
  248.         structures. It is perfectly possible to have some redundancy
  249.         (that is: possible loops) in distribution.
  250.         
  251.         
  252.         
  253.                                 +------+                     
  254.                                 |  N1  |                     
  255.                                 +------+                     
  256.                                  /    \                      
  257.                                 /      \                     
  258.                                /        \                    
  259.                               \/        \/                  
  260.                         +------+        +------+             
  261.                         |  N2  | <----> |  N3  |             
  262.                         +------+        +------+             
  263.                          /    \          /    \              
  264.                         /      \        /      \             
  265.                        /        \      /        \            
  266.                       \/        \/    \/        \/          
  267.                 +------+        +------+        +------+
  268.                 |  N4  | <----- |  N5  | <----> |  N6  |     
  269.                 +------+        +------+        +------+
  270.                  /    \               \               /\   
  271.                 /      \               \               \  
  272.                /        \               \               \       
  273.               \/        \/              \/              \/     
  274.         +------+        +------+        +------+        +------+
  275.         |  N7  | <----> |  N8  |        |  N9  | <----> |  N10 |
  276.         +------+        +------+        +------+        +------+
  277.         
  278.         
  279.         Picture 1
  280.         
  281.         
  282.         As can be seen from the picture 1, it is possible to have
  283.         files coming in from many different input servers. For
  284.         example N5 (Node 5) could receive files from nodes 2, 3 and
  285.         6.  However, it is expected to accept only the first copy of
  286.         the same version. Accepting in this context means both
  287.         installing it locally and distributing it further.
  288.  
  289.  
  290. Kaittola                 Expires: January, 1994                 [Page 5]
  291.  
  292. DRAFT                 File distribution - structure                 DRAFT
  293.  
  294.  
  295.         
  296.         As node 4 makes some local modifications to files it sends
  297.         to N7 and N8 it can't send files to N5. (Actually it could
  298.         send unmodified files.) Naturally N8 can't send anything
  299.         from N9 either (or the other way round).
  300.         
  301.         Picture 1 also shows that mappings may be passed from N10 to
  302.         N6 although N6 seems to be closer to the root.
  303.         
  304.         There are only three kinds of nodes in this approach: the
  305.         root, a local root and normal nodes. The local root is a
  306.         node that may make local modifications (N4 in this
  307.         example).  The root is a source of information
  308.         distribution.
  309.         
  310.         For different hierarchies there may be different
  311.         distribution trees with different roots.
  312.         
  313.         
  314. 2.1. Receiving a file
  315.         
  316.         When a new file is announced the following actions take
  317.         place. (Look at picture 1 in [DST-DIALOG].)
  318.         
  319.         1) The validity of the announcement is checked.
  320.         
  321.         An announcement is considered to be valid if it comes from
  322.         an approved source (IAM line), it is about an approved file
  323.         and it is newer than the local version.
  324.         
  325.         2) If the announcement is valid it is requested to be sent.
  326.         
  327.         It is possible to request a file from many different
  328.         servers, if announcements of it are received from multiple
  329.         servers before the file is actually received.
  330.         
  331.         A password and a serial number are included in the request.
  332.         
  333.         3) The validity of the received file is checked.
  334.         
  335.         A file is valid if it comes from an approved source (IAM
  336.         line) with a serial number and a password that match and are
  337.         not too old (a local database is needed), it contains
  338.         requested file(s) and the checksum is correct. On same
  339.         applications also the contents of a file may be checked.
  340.         
  341.         If the same file (or a newer version of it) has already been
  342.         received then the new file will be discarded.
  343.         
  344.         If steps 1-3 have been succesfull the file is installed
  345.         locally and the sending phase starts (if the node isn't a
  346.  
  347.  
  348. Kaittola                 Expires: January, 1994                 [Page 6]
  349.  
  350. DRAFT                 File distribution - structure                 DRAFT
  351.  
  352.  
  353.         receive-only node).
  354.         
  355.         
  356. 2.2. Sending files
  357.         
  358.         When a file is accepted locally it will be announced to the
  359.         nodes who are being fed with new files.
  360.         
  361.         After announcements have been sent no actions are needed
  362.         unless a new file is requested by someone.
  363.         
  364.         In response to a request a file is sent out provided that
  365.         it is present locally. Access restrictions are normally
  366.         expected not to exist, although it is possible to limit the
  367.         possible set of recipients.
  368.         
  369.         If more than one file has been requested, or the requested
  370.         file is too big, it is possible to split the reply into
  371.         multiple messages to limit the size of the reply messages.
  372.         
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406. Kaittola                 Expires: January, 1994                 [Page 7]
  407.  
  408. DRAFT                 File distribution - structure                 DRAFT
  409.  
  410.  
  411. 3. Client and server roles
  412.         
  413.         A generic node consists of two parts, namely client and
  414.         server. (Some nodes may in practice be only clients or
  415.         servers. In that case the other part is considered as being
  416.         inactive.)
  417.         
  418.         
  419.                 +---+
  420.                 | C |
  421.                 +---+
  422.                 | S |
  423.                 +---+
  424.                     /   \
  425.                    /     \
  426.                   /       \
  427.                  /         \
  428.              +---+           +---+
  429.              | C |           | C |
  430.              +---+           +---+
  431.              | S |           | S |        
  432.              +---+           +---+
  433.                |
  434.                |
  435.                |
  436.              +---+
  437.              | C |
  438.              +---+
  439.              | S |
  440.              +---+
  441.         
  442.         Picture 2
  443.         
  444.         
  445.         This document explains the over-all structure.
  446.         
  447.         
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464. Kaittola                 Expires: January, 1994                 [Page 8]
  465.  
  466. DRAFT                 File distribution - structure                 DRAFT
  467.  
  468.  
  469. 4. Security consideratins
  470.         
  471.         Security is based on keys that are sent with the request and
  472.         copied in a reply. This gives a protection against forged
  473.         messages. It doesn't work if an ethernet is tapped or some
  474.         relaying machine is cracked.  However, this is considered to
  475.         be such an extreme situation that such a cracker could in
  476.         any case cause a great deal of trouble.
  477.         
  478.         
  479. References
  480.         
  481.         [DST-DIALOG]    Mail based file distribution - Part 1:
  482.                 Dialog between two nodes
  483.         [DST-MHS]    One more companion document to be written
  484.                 (informational)
  485.         
  486.         
  487. Acknowledgements
  488.         
  489.         Various peoples have contributed on this document. It is
  490.         impossible to list everyone here. However, I'd like to give
  491.         special thanks to the following:
  492.         
  493.         Urs Eppenberger, Allan Cargille, Harald Tveit Alvestrand,
  494.         Paul Andre Pays and Jim Romaquera from RARE WG1 / RARE
  495.         WG-MSG / COSINE MHS managers / IETF X.400 ops have
  496.         contributed and kept me going.
  497.         
  498.         Pasi Ojala wrote the first implementation while I wrote this
  499.         paper. He also suggested many improvements. He developed the
  500.         approach used in Hamming coding.
  501.         
  502.         Keijo Ruohonen helped with the Hamming coding.
  503.         
  504.         
  505. Author's address
  506.         
  507.         Marko Kaittola
  508.         FUNET
  509.         c/o Tampere University of Technology
  510.         Software Systems Laboratory
  511.         P.O. Box 553
  512.         SF-33101 Tampere
  513.         Finland
  514.         
  515.         E-mail: Marko.Kaittola@funet.fi
  516.                 G=Marko; S=Kaittola; O=funet; A=fumail; C=fi;
  517.  
  518.  
  519.  
  520.  
  521.  
  522. Kaittola                 Expires: January, 1994                 [Page 9]
  523.